David Howells [Wed, 5 Apr 2017 16:40:29 +0000 (17:40 +0100)]
efi: Lock down the kernel if booted in secure boot mode
UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels. Certain use cases may also
require that all kernel modules also be signed. Add a configuration option
that to lock down the kernel - which includes requiring validly signed
modules - if the kernel is secure-booted.
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0041-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mo.patch
David Howells [Wed, 5 Apr 2017 16:40:29 +0000 (17:40 +0100)]
Add the ability to lock down access to the running kernel image
Provide a single call to allow kernel code to determine whether the system
should be locked down, thereby disallowing various accesses that might
allow the running kernel image to be changed including the loading of
modules that aren't validly signed with a key we recognise, fiddling with
MSR registers and disallowing hibernation,
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0040-Add-the-ability-to-lock-down-access-to-the-running-k.patch
Josh Boyer [Wed, 5 Apr 2017 16:40:29 +0000 (17:40 +0100)]
efi: Add EFI_SECURE_BOOT bit
UEFI machines can be booted in Secure Boot mode. Add a EFI_SECURE_BOOT bit
that can be passed to efi_enabled() to find out whether secure boot is
enabled.
This will be used by the SysRq+x handler, registered by the x86 arch, to find
out whether secure boot mode is enabled so that it can be disabled.
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0039-efi-Add-EFI_SECURE_BOOT-bit.patch
David Howells [Tue, 4 Apr 2017 15:54:30 +0000 (16:54 +0100)]
Annotate hardware config module parameters in sound/pci/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in sound/pci/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: alsa-devel@alsa-project.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0038-Annotate-hardware-config-module-parameters-in-sound-.patch
David Howells [Tue, 4 Apr 2017 15:54:30 +0000 (16:54 +0100)]
Annotate hardware config module parameters in sound/oss/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in sound/oss/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: Riccardo Facchetti <fizban@tin.it>
cc: Andrew Veliath <andrewtv@usa.net>
cc: alsa-devel@alsa-project.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0037-Annotate-hardware-config-module-parameters-in-sound-.patch
David Howells [Tue, 4 Apr 2017 15:54:30 +0000 (16:54 +0100)]
Annotate hardware config module parameters in sound/isa/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in sound/isa/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: alsa-devel@alsa-project.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0036-Annotate-hardware-config-module-parameters-in-sound-.patch
David Howells [Tue, 4 Apr 2017 15:54:30 +0000 (16:54 +0100)]
Annotate hardware config module parameters in sound/drivers/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in sound/drivers/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaroslav Kysela <perex@perex.cz>
cc: Takashi Iwai <tiwai@suse.com>
cc: alsa-devel@alsa-project.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0035-Annotate-hardware-config-module-parameters-in-sound-.patch
David Howells [Tue, 4 Apr 2017 15:54:29 +0000 (16:54 +0100)]
Annotate hardware config module parameters in fs/pstore/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in fs/pstore/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Anton Vorontsov <anton@enomsg.org>
cc: Colin Cross <ccross@android.com>
cc: Kees Cook <keescook@chromium.org>
cc: Tony Luck <tony.luck@intel.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0034-Annotate-hardware-config-module-parameters-in-fs-pst.patch
David Howells [Tue, 4 Apr 2017 15:54:29 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/watchdog/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/watchdog/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
cc: Wim Van Sebroeck <wim@iguana.be>
cc: Zwane Mwaikambo <zwanem@gmail.com>
cc: linux-watchdog@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0033-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:29 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/video/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/video/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jaya Kumar <jayalk@intworks.biz>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: linux-fbdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0032-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:29 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/tty/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/tty/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Jiri Slaby <jslaby@suse.com>
cc: linux-serial@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0031-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:28 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/staging/vme/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/staging/vme/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Martyn Welch <martyn@welchs.me.uk>
cc: Manohar Vanga <manohar.vanga@gmail.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: devel@driverdev.osuosl.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0030-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:28 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/staging/speakup/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/staging/speakup/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: speakup@linux-speakup.org
cc: devel@driverdev.osuosl.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0029-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:28 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/staging/media/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/staging/media/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mauro Carvalho Chehab <mchehab@kernel.org>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: linux-media@vger.kernel.org
cc: devel@driverdev.osuosl.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0028-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:27 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/scsi/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/scsi/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Juergen E. Fischer" <fischer@norbit.de>
cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com>
cc: "Martin K. Petersen" <martin.petersen@oracle.com>
cc: Dario Ballabio <ballabio_dario@emc.com>
cc: Finn Thain <fthain@telegraphics.com.au>
cc: Michael Schmitz <schmitzmic@gmail.com>
cc: Achim Leubner <achim_leubner@adaptec.com>
cc: linux-scsi@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0027-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:27 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/pcmcia/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/pcmcia/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pcmcia@lists.infradead.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0026-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:27 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/pci/hotplug/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/pci/hotplug/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
cc: Scott Murray <scott@spiteful.org>
cc: linux-pci@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0025-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:27 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/parport/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/parport/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0024-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:27 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/wireless/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/wireless/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Kalle Valo <kvalo@codeaurora.org>
cc: linux-wireless@vger.kernel.org
cc: netdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0023-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:27 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/wan/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/wan/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Jan \"Yenya\" Kasprzak" <kas@fi.muni.cz>
cc: netdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0022-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:26 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/irda/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/irda/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Samuel Ortiz <samuel@sortiz.org>
cc: netdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0021-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:26 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/hamradio/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/hamradio/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Thomas Sailer <t.sailer@alumni.ethz.ch>
cc: Joerg Reuter <jreuter@yaina.de>
cc: linux-hams@vger.kernel.org
cc: netdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0020-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:26 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/ethernet/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/ethernet/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Steffen Klassert <klassert@mathematik.tu-chemnitz.de>
cc: Jaroslav Kysela <perex@perex.cz>
cc: netdev@vger.kernel.org
cc: linux-parisc@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0019-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:25 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/can/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/can/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
cc: Wolfgang Grandegger <wg@grandegger.com>
cc: linux-can@vger.kernel.org
cc: netdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0018-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:25 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/arcnet/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/arcnet/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
cc: netdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0017-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:25 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/net/appletalk/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/net/appletalk/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
cc: netdev@vger.kernel.org
[bwh: Drop changes to cops driver, which we removed]
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0016-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:25 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/mmc/host/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/mmc/host/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Pierre Ossman <pierre@ossman.eu>
cc: Ulf Hansson <ulf.hansson@linaro.org>
cc: linux-mmc@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0015-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:24 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/misc/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/misc/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0014-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:24 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/media/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/media/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Mauro Carvalho Chehab <mchehab@kernel.org>
cc: mjpeg-users@lists.sourceforge.net
cc: linux-media@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0013-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:24 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/isdn/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/isdn/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Karsten Keil <isdn@linux-pingi.de>
cc: netdev@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0012-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:23 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/input/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/input/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
cc: linux-input@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0011-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:23 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/iio/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/iio/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Jonathan Cameron <jic23@kernel.org>
cc: linux-iio@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0010-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:23 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/i2c/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/i2c/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Wolfram Sang <wsa@the-dreams.de>
cc: Jean Delvare <jdelvare@suse.com>
cc: linux-i2c@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0009-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:22 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/gpio/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/gpio/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
cc: Alexandre Courbot <gnurou@gmail.com>
cc: linux-gpio@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0008-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:22 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/cpufreq/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/cpufreq/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: "Rafael J. Wysocki" <rjw@rjwysocki.net>
cc: Viresh Kumar <viresh.kumar@linaro.org>
cc: linux-pm@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0007-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:22 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/clocksource/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/clocksource/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Daniel Lezcano <daniel.lezcano@linaro.org>
cc: Thomas Gleixner <tglx@linutronix.de>
cc: linux-kernel@vger.kernel.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0006-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:22 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/char/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/char/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Arnd Bergmann <arnd@arndb.de>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0005-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:21 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/char/mwave/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/char/mwave/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0004-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:21 +0000 (16:54 +0100)]
Annotate hardware config module parameters in drivers/char/ipmi/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in drivers/char/ipmi/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Corey Minyard <cminyard@mvista.com>
cc: openipmi-developer@lists.sourceforge.net
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0003-Annotate-hardware-config-module-parameters-in-driver.patch
David Howells [Tue, 4 Apr 2017 15:54:21 +0000 (16:54 +0100)]
Annotate hardware config module parameters in arch/x86/mm/
When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image. Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.
To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify. The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.
Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.
This patch annotates drivers in arch/x86/mm/.
Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Steven Rostedt <rostedt@goodmis.org>
cc: Ingo Molnar <mingo@kernel.org>
cc: Thomas Gleixner <tglx@linutronix.de>
cc: "H. Peter Anvin" <hpa@zytor.com>
cc: x86@kernel.org
cc: linux-kernel@vger.kernel.org
cc: nouveau@lists.freedesktop.org
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0002-Annotate-hardware-config-module-parameters-in-arch-x.patch
David Howells [Tue, 4 Apr 2017 15:54:21 +0000 (16:54 +0100)]
Annotate module params that specify hardware parameters (eg. ioport)
Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).
This will enable such parameters to be locked down in the core parameter
parser for secure boot support.
I've also included annotations as to what sort of hardware configuration
each module is dealing with for future use. Some of these are
straightforward (ioport, iomem, irq, dma), but there are also:
(1) drivers that switch the semantics of a parameter between ioport and
iomem depending on a second parameter,
(2) drivers that appear to reserve a CPU memory buffer at a fixed address,
(3) other parameters, such as bus types and irq selection bitmasks.
For the moment, the hardware configuration type isn't actually stored,
though its validity is checked.
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0001-Annotate-module-params-that-specify-hardware-paramet.patch
Ben Hutchings [Sat, 4 Mar 2017 01:44:15 +0000 (01:44 +0000)]
Kbuild.include: addtree: Remove quotes before matching path
systemtap currently fails to build modules when the kernel source and
object trees are separate.
systemtap adds something like -I"/usr/share/systemtap/runtime" to
EXTRA_CFLAGS, and addtree should not adjust this as it's specifying an
absolute directory. But since make has no understanding of shell
quoting, it does anyway.
For a long time this didn't matter, because addtree would still emit
the original -I option after the adjusted one. However, commit
db547ef19064 ("Kbuild: don't add obj tree in additional includes")
changed it to remove the original -I option.
Remove quotes (both double and single) before matching against the
excluded patterns.
References: https://bugs.debian.org/856474
Reported-by: Jack Henschel <jackdev@mailbox.org>
Reported-by: Ritesh Raj Sarraf <rrs@debian.org>
Fixes: db547ef19064 ("Kbuild: don't add obj tree in additional includes")
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-include-addtree-remove-quotes-before-matching-path.patch
Ben Hutchings [Wed, 11 Jan 2017 04:30:40 +0000 (04:30 +0000)]
Partially revert "usb: Kconfig: using select for USB_COMMON dependency"
This reverts commit
cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for
USB_LED_TRIG. This config symbol has bool type and enables extra code
in usb_common itself, not a separate driver. Enabling it should not
force usb_common to be built-in!
Fixes: cb9c1cfc8692 ("usb: Kconfig: using select for USB_COMMON dependency")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name partially-revert-usb-kconfig-using-select-for-usb_co.patch
Ben Hutchings [Fri, 26 Aug 2016 00:31:28 +0000 (01:31 +0100)]
kbuild: Do not use hyphen in exported variable name
This definition in Makefile.dtbinst:
export dtbinst-root ?= $(obj)
should define and export dtbinst-root when handling the root dts
directory, and do nothing in the subdirectories. However, the
variable does not reliably get exported to the environment, perhaps
because its name contains a hyphen.
Rename the variable to dtbinst_root.
References: https://bugs.debian.org/833561
Fixes: 323a028d39cdi ("dts, kbuild: Implement support for dtb vendor subdirs")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-do-not-use-hyphen-in-exported-variable-name.patch
Ben Hutchings [Wed, 13 Apr 2016 20:48:06 +0000 (21:48 +0100)]
fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers
This helps initramfs builders and other tools to find the full
dependencies of a module.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name fs-add-module_softdep-declarations-for-hard-coded-cr.patch
Ian Campbell [Wed, 20 Nov 2013 08:30:14 +0000 (08:30 +0000)]
phy/marvell: disable 4-port phys
The Marvell PHY was originally disabled because it can cause networking
failures on some systems. According to Lennert Buytenhek this is because some
of the variants added did not share the same register layout. Since the known
cases are all 4-ports disable those variants (indicated by a 4 in the
penultimate position of the model name) until they can be audited for
correctness.
[bwh: Also #if-out the init functions for these PHYs to avoid
compiler warnings]
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name disable-some-marvell-phys.patch
Ben Hutchings [Sat, 19 Oct 2013 18:43:35 +0000 (19:43 +0100)]
kbuild: Use -nostdinc in compile tests
gcc 4.8 and later include <stdc-predef.h> by default. In some
versions of eglibc that includes <bits/predefs.h>, but that may be
missing when building with a biarch compiler. Also <stdc-predef.h>
itself could be missing as we are only trying to build a kernel, not
userland.
The -nostdinc option disables this, though it isn't explicitly
documented. This option is already used when actually building
the kernel, but not by cc-option and other tests. This can result
in silently miscompiling the kernel.
References: https://bugs.debian.org/717557
References: https://bugs.debian.org/726861
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-use-nostdinc-in-compile-tests.patch
Enric Balletbo i Serra [Wed, 3 May 2017 09:56:29 +0000 (10:56 +0100)]
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-veyron
Add reference to the Mali GPU device tree node on rk3288-veyron.
Tested on Minnie and Jerry boards.
Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-veyro.patch
Guillaume Tucker [Wed, 3 May 2017 09:56:28 +0000 (10:56 +0100)]
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-firefly
Add reference to the Mali GPU device tree node on rk3288-firefly.
Tested on Firefly board.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-firef.patch
Guillaume Tucker [Wed, 3 May 2017 09:56:27 +0000 (10:56 +0100)]
ARM: dts: rockchip: enable ARM Mali GPU on rk3288-rock2-som
Add reference to the Mali GPU device tree node on the
rk3288-rock2-som platform. Tested on a Radxa Rock2 Square board.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-enable-arm-mali-gpu-on-rk3288-rock2.patch
Guillaume Tucker [Wed, 3 May 2017 09:56:26 +0000 (10:56 +0100)]
ARM: dts: rockchip: add ARM Mali GPU node for rk3288
Add Mali GPU device tree node for the rk3288 SoC, with devfreq
opp table.
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name arm-dts-rockchip-add-arm-mali-gpu-node-for-rk3288.patch
Guillaume Tucker [Wed, 3 May 2017 09:56:25 +0000 (10:56 +0100)]
dt-bindings: gpu: add bindings for the ARM Mali Midgard GPU
The ARM Mali Midgard GPU family is present in a number of SoCs
from many different vendors such as Samsung Exynos and Rockchip.
Import the device tree bindings documentation from the r16p0
release of the Mali Midgard GPU kernel driver:
https://developer.arm.com/-/media/Files/downloads/mali-drivers/kernel/mali-midgard-gpu/TX011-SW-99002-r16p0-00rel0.tgz
Remove the copyright and GPL licence header as deemed not necessary.
Redesign the "compatible" property strings to list all the Mali
Midgard GPU types and add vendor specific ones.
Drop the "clock-names" property as the Mali Midgard GPU uses only one
clock (the driver now needs to call clk_get with NULL).
Convert the "interrupt-names" property values to lower-case: "job",
"mmu" and "gpu".
Replace the deprecated "operating-points" optional property with
"operating-points-v2".
Omit the following optional properties in this initial version as they
are only used in very specific cases:
* snoop_enable_smc
* snoop_disable_smc
* jm_config
* power_model
* system-coherency
* ipa-model
Update the example accordingly to reflect all these changes, based on
rk3288 mali-t760.
CC: John Reitan <john.reitan@arm.com>
Signed-off-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic features/arm
Gbp-Pq: Name dt-bindings-gpu-add-bindings-for-the-arm-mali-midgar.patch
Ben Hutchings [Fri, 25 Jul 2014 00:16:15 +0000 (01:16 +0100)]
x86: Make x32 syscall support conditional on a kernel parameter
Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).
Still, adding another flavour just to turn on x32 seems wasteful. And
the only differences on syscall entry are two instructions (mask out
the x32 flag and compare the syscall number).
So pad the standard comparison with a nop and add a kernel parameter
"syscall.x32" which controls whether this is replaced with the x32
version at boot time. Add a Kconfig parameter to set the default.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch
Ben Hutchings [Mon, 5 Dec 2011 04:00:58 +0000 (04:00 +0000)]
x86: memtest: WARN if bad RAM found
Since this is not a particularly thorough test, if we find any bad
bits of RAM then there is a fair chance that there are other bad bits
we fail to detect.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-memtest-WARN-if-bad-RAM-found.patch
Aurelien Jarno [Sun, 20 Jul 2014 17:16:31 +0000 (19:16 +0200)]
MIPS: Loongson 3: Add Loongson LS3A RS780E 1-way machine definition
Add a Loongson LS3A RS780E 1-way machine definition, which only differs
from other Loongson 3 based machines by the UART base clock speed.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
[bwh: Forward-ported to 4.2]
Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-Loongson-3-Add-Loongson-LS3A-RS780E-1-way-machi.patch
Aurelien Jarno [Mon, 17 Jul 2017 02:01:21 +0000 (03:01 +0100)]
MIPS: increase MAX_PHYSMEM_BITS on Loongson 3 only
Commit
c4617318 broke Loongson-2 support and maybe even more by increasing
the value of MAX_PHYSMEM_BITS. At it is currently only needed on
Loongson-3, define it conditionally.
Note: this should be replace by upstream fix when available.
Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-increase-MAX-PHYSMEM-BITS-on-Loongson-3-only.patch
Yang Jiaxun [Tue, 4 Jul 2017 14:39:19 +0000 (14:39 +0000)]
platform/x86: ideapad-laptop: Add several models to no_hw_rfkill
Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.
Fix it by adding those models to no_hw_rfkill_list.
Signed-off-by: Yang Jiaxun <yjx@flygoat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-several-models-to-no.patch
Sven Eckelmann [Sat, 1 Jul 2017 06:20:18 +0000 (08:20 +0200)]
platform/x86: ideapad-laptop: Add IdeaPad V510-15IKB to no_hw_rfkill
Like other Lenovo models the IdeaPad V510-15IKB does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.
Add the IdeaPad V510-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v510-15ikb-t.patch
Olle Liljenzin [Sun, 18 Jun 2017 12:37:58 +0000 (14:37 +0200)]
platform/x86: ideapad-laptop: Add Y720-15IKBN to no_hw_rfkill
Lenovo Legion Y720-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.
Add the model to the list of models without rfkill switch.
Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y720-15ikbn-to-no_hw.patch
Olle Liljenzin [Sun, 18 Jun 2017 11:09:31 +0000 (13:09 +0200)]
platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill
Lenovo Legion Y520-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.
Add the model to the list of models without rfkill switch.
Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y520-15ikbn-to-no_hw.patch
Andy Shevchenko [Tue, 21 Feb 2017 19:53:48 +0000 (20:53 +0100)]
platform/x86: ideapad-laptop: Add IdeaPad V310-15ISK to no_hw_rfkill
Like other Lenovo models the IdeaPad V310-15ISK does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.
Add the IdeaPad V310-15ISK to the no_hw_rfkill DMI list and allows using
the built-in radios.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v310-15isk-t.patch
Sven Rebhan [Tue, 21 Feb 2017 19:53:48 +0000 (20:53 +0100)]
platform/x86: ideapad-laptop: Add IdeaPad 310-15IKB to no_hw_rfkill
Like other Lenovo models the IdeaPad 310-15IKB does not have an hw rfkill
switch. This results in hard-blocked radios after boot, resulting in
always blocked radios rendering them unusable.
Add the IdeaPad 310-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.
Signed-off-by: Sven Rebhan <Sven.Rebhan@googlemail.com>
[andy: massaged commit message]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-310-15ikb-to.patch
Mika Westerberg [Wed, 17 May 2017 10:25:14 +0000 (13:25 +0300)]
pinctrl: cherryview: Extend the Chromebook DMI quirk to Intel_Strago systems
It turns out there are quite many Chromebooks out there that have the
same keyboard issue than Acer Chromebook. All of them are based on
Intel_Strago reference and report their DMI_PRODUCT_FAMILY as
"Intel_Strago" (Samsung Chromebook 3 and Cyan Chromebooks are exceptions
for which we add separate entries).
Instead of adding each machine to the quirk table, we use
DMI_PRODUCT_FAMILY of "Intel_Strago" that hopefully covers most of the
machines out there currently.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=194945
Suggested: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name pinctrl-cherryview-extend-the-chromebook-dmi-quirk-t.patch
Mika Westerberg [Wed, 17 May 2017 10:25:12 +0000 (13:25 +0300)]
firmware: dmi: Add DMI_PRODUCT_FAMILY identification string
Sometimes it is more convenient to be able to match a whole family of
products, like in case of bunch of Chromebooks based on Intel_Strago to
apply a driver quirk instead of quirking each machine one-by-one.
This adds support for DMI_PRODUCT_FAMILY identification string and also
exports it to the userspace through sysfs attribute just like the
existing ones.
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Gbp-Pq: Topic features/all
Gbp-Pq: Name firmware-dmi-add-dmi_product_family-identification-s.patch
Ben Hutchings [Fri, 17 Feb 2017 01:30:30 +0000 (01:30 +0000)]
ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419
The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals). Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.
Reported-by: gmbh@gazeta.pl
Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017
Cc: stable@vger.kernel.org # 3.15+
Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch
Ben Hutchings [Thu, 16 Mar 2017 03:05:43 +0000 (03:05 +0000)]
Don't WARN about expected W+X pages on Xen
Currently Xen PV domains (or at least dom0) on amd64 tend to have a
large number of low kernel pages with W+X permissions. It's not
obvious how to fix this, and we're not going to get any new
information by WARNing about this, but we do still want to hear about
other W+X cases. So add a condition to the WARN_ON.
Gbp-Pq: Topic debian
Gbp-Pq: Name amd64-don-t-warn-about-expected-w+x-pages-on-xen.patch
Adam Borowski [Tue, 28 Mar 2017 14:55:05 +0000 (16:55 +0200)]
btrfs: warn about RAID5/6 being experimental at mount time
Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.
Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]
Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch
Ben Hutchings [Wed, 13 Jul 2016 00:37:22 +0000 (01:37 +0100)]
fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS
Various free and proprietary AV products use this feature and users
apparently want it. But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that. So warn and taint the kernel if this feature is
actually used.
Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch
Ben Hutchings [Sat, 18 Mar 2017 20:47:58 +0000 (20:47 +0000)]
fjes: Disable auto-loading
fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device. Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.
Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch
Ben Hutchings [Sat, 20 Apr 2013 14:52:02 +0000 (15:52 +0100)]
viafb: Autoload on OLPC XO 1.5 only
It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match. Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.
However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch
Ben Hutchings [Wed, 5 Feb 2014 23:01:30 +0000 (23:01 +0000)]
snd-pcsp: Disable autoload
There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
play barely recognisable renditions of sampled sound
snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that. On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.
In case anyone finds snd-pcsp useful, we continue to build it. But
remove the alias, to ensure it's not loaded where it's not wanted.
Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch
Ben Hutchings [Sun, 31 Mar 2013 02:58:04 +0000 (03:58 +0100)]
cdc_ncm,cdc_mbim: Use NCM by default
Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.
Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.
Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch
Ben Hutchings [Mon, 11 Jan 2016 15:23:55 +0000 (15:23 +0000)]
security,perf: Allow further restriction of perf_event_open
When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.
This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN). This version doesn't include making
the variable read-only. It also allows enabling further restriction
at run-time regardless of whether the default is changed.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch
Serge Hallyn [Fri, 31 May 2013 18:12:12 +0000 (19:12 +0100)]
add sysctl to disallow unprivileged CLONE_NEWUSER by default
add sysctl to disallow unprivileged CLONE_NEWUSER by default
This is a short-term patch. Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces. However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]
Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch
Ben Hutchings [Wed, 19 Jun 2013 03:35:28 +0000 (04:35 +0100)]
yama: Disable by default
Gbp-Pq: Topic debian
Gbp-Pq: Name yama-disable-by-default.patch
Ben Hutchings [Wed, 16 Mar 2011 03:17:06 +0000 (03:17 +0000)]
sched: Do not enable autogrouping by default
We want to provide the option of autogrouping but without enabling
it by default yet.
Gbp-Pq: Topic debian
Gbp-Pq: Name sched-autogroup-disabled.patch
Ben Hutchings [Fri, 2 Nov 2012 05:32:06 +0000 (05:32 +0000)]
fs: Enable link security restrictions by default
This reverts commit
561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').
Gbp-Pq: Topic debian
Gbp-Pq: Name fs-enable-link-security-restrictions-by-default.patch
Ben Hutchings [Thu, 16 Feb 2017 19:09:17 +0000 (19:09 +0000)]
dccp: Disable auto-loading as mitigation against local exploits
We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.
The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch
Ben Hutchings [Sat, 20 Nov 2010 02:24:55 +0000 (02:24 +0000)]
decnet: Disable auto-loading as mitigation against local exploits
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
rds: Disable auto-loading as mitigation against local exploits
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch
Ben Hutchings [Fri, 19 Nov 2010 02:12:48 +0000 (02:12 +0000)]
af_802154: Disable auto-loading as mitigation against local exploits
Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation. We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.
The 'af_802154' (IEEE 802.15.4) protocol is not widely used, was
not present in the 'lenny' kernel, and seems to receive only sporadic
maintenance. Therefore disable auto-loading.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name af_802154-Disable-auto-loading-as-mitigation-against.patch
J. R. Okajima [Fri, 30 Jun 2017 12:04:46 +0000 (21:04 +0900)]
aufs4.11.7+ standalone patch
Patch headers added by debian/patches/features/all/aufs4/gen-patch
aufs4.11.7+ standalone patch
Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-standalone.patch
J. R. Okajima [Fri, 30 Jun 2017 12:04:46 +0000 (21:04 +0900)]
aufs4.11.7+ mmap patch
Patch headers added by debian/patches/features/all/aufs4/gen-patch
aufs4.11.7+ mmap patch
Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-mmap.patch
J. R. Okajima [Fri, 30 Jun 2017 12:04:46 +0000 (21:04 +0900)]
aufs4.11.7+ base patch
Patch headers added by debian/patches/features/all/aufs4/gen-patch
aufs4.11.7+ base patch
Gbp-Pq: Topic features/all/aufs4
Gbp-Pq: Name aufs4-base.patch
Ben Hutchings [Tue, 8 Jan 2013 03:25:52 +0000 (03:25 +0000)]
radeon: Firmware is required for DRM and KMS on R600 onward
radeon requires firmware/microcode for the GPU in all chips, but for
newer chips (apparently R600 'Evergreen' onward) it also expects
firmware for the memory controller and other sub-blocks.
radeon attempts to gracefully fall back and disable some features if
the firmware is not available, but becomes unstable - the framebuffer
and/or system memory may be corrupted, or the display may stay black.
Therefore, perform a basic check for the existence of
/lib/firmware/radeon when a device is probed, and abort if it is
missing, except for the pre-R600 case.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name radeon-firmware-is-required-for-drm-and-kms-on-r600-onward.patch
Ben Hutchings [Sun, 9 Dec 2012 16:40:31 +0000 (16:40 +0000)]
firmware: Remove redundant log messages from drivers
Now that firmware_class logs every success and failure consistently,
many other log messages can be removed from drivers.
This will probably need to be split up into multiple patches prior to
upstream submission.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware-remove-redundant-log-messages-from-drivers.patch
Ben Hutchings [Sun, 9 Dec 2012 16:02:00 +0000 (16:02 +0000)]
firmware_class: Log every success and failure against given device
The hundreds of users of request_firmware() have nearly as many
different log formats for reporting failures. They also have only the
vaguest hint as to what went wrong; only firmware_class really knows
that. Therefore, add specific log messages for the failure modes that
aren't currently logged.
In case of a driver that tries multiple names, this may result in the
impression that it failed to initialise. Therefore, also log successes.
This makes many error messages in drivers redundant, which will be
removed in later patches.
This does not cover the case where we fall back to a user-mode helper
(which is no longer enabled in Debian).
NOTE: hw-detect will depend on the "firmware: failed to load %s (%d)\n"
format to detect missing firmware.
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name firmware_class-log-every-success-and-failure.patch
Ben Hutchings [Mon, 17 Jul 2017 02:01:21 +0000 (03:01 +0100)]
iwlwifi: Do not request unreleased firmware for IWL6000
The iwlwifi driver currently supports firmware API versions 4-6 for
these devices. It will request the file for the latest supported
version and then fall back to earlier versions. However, the latest
version that has actually been released is 4, so we expect the
requests for versions 6 and then 5 to fail.
The installer appears to report any failed request, and it is probably
not easy to detect that this particular failure is harmless. So stop
requesting the unreleased firmware.
Gbp-Pq: Topic debian
Gbp-Pq: Name iwlwifi-do-not-request-unreleased-firmware.patch
Ben Hutchings [Mon, 24 Aug 2009 22:19:58 +0000 (23:19 +0100)]
af9005: Use request_firmware() to load register init script
Read the register init script from the Windows driver. This is sick
but should avoid the potential copyright infringement in distributing
a version of the script which is directly derived from the driver.
Gbp-Pq: Topic features/all
Gbp-Pq: Name drivers-media-dvb-usb-af9005-request_firmware.patch
Bastian Blank [Fri, 7 Oct 2011 20:37:52 +0000 (21:37 +0100)]
Install perf scripts non-executable
[bwh: Forward-ported to 3.12]
Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-install.patch
Bastian Blank [Mon, 26 Sep 2011 12:53:12 +0000 (13:53 +0100)]
Create manpages and binaries including the version
[bwh: Fix version insertion in perf man page cross-references and perf
man page title. Install bash_completion script for perf with a
version-dependent name. And do the same for trace.]
Gbp-Pq: Topic debian
Gbp-Pq: Name tools-perf-version.patch
Chris Boot [Mon, 1 Jul 2013 22:10:02 +0000 (23:10 +0100)]
modpost symbol prefix setting
[bwh: The original version of this was added by Bastian Blank. The
upstream code includes <generated/autoconf.h> so that <linux/export.h>
can tell whether C symbols have an underscore prefix. Since we build
modpost separately from the kernel, <generated/autoconf.h> won't exist.
However, no Debian Linux architecture uses the symbol prefix, so we
can simply omit it.]
Gbp-Pq: Topic debian
Gbp-Pq: Name modpost-symbol-prefix.patch
Ben Hutchings [Tue, 14 Sep 2010 03:33:34 +0000 (04:33 +0100)]
Kbuild: kconfig: Verbose version of --listnewconfig
If the KBUILD_VERBOSE environment variable is set to non-zero, show
the default values of new symbols and not just their names.
Based on work by Bastian Blank <waldi@debian.org> and
maximilian attems <max@stro.at>. Simplified by Michal Marek
<mmarek@suse.cz>.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name Kbuild-kconfig-Verbose-version-of-listnewconfig.patch
Debian Kernel Team [Mon, 17 Jul 2017 02:01:21 +0000 (03:01 +0100)]
powerpcspe-omit-uimage
Gbp-Pq: Topic debian
Gbp-Pq: Name powerpcspe-omit-uimage.patch
Nobuhiro Iwamatsu [Mon, 17 Jul 2017 02:01:21 +0000 (03:01 +0100)]
Fix uImage build
[bwh: This was added without a description, but I think it is dealing
with a similar issue to powerpcspe-omit-uimage.patch]
Gbp-Pq: Topic debian
Gbp-Pq: Name arch-sh4-fix-uimage-build.patch
Ben Hutchings [Mon, 13 Sep 2010 01:16:18 +0000 (02:16 +0100)]
Partially revert "MIPS: Add -Werror to arch/mips/Kbuild"
This reverts commit
66f9ba101f54bda63ab1db97f9e9e94763d0651b.
We really don't want to add -Werror anywhere.
Gbp-Pq: Topic debian
Gbp-Pq: Name mips-disable-werror.patch
Ian Campbell [Thu, 17 Jan 2013 08:55:21 +0000 (08:55 +0000)]
Tweak gitignore for Debian pkg-kernel using git svn.
[bwh: Tweak further for pure git]
Gbp-Pq: Topic debian
Gbp-Pq: Name gitignore.patch
Bastian Blank [Sun, 22 Feb 2009 14:39:35 +0000 (15:39 +0100)]
kbuild: Make the toolchain variables easily overwritable
Allow make variables to be overridden for each flavour by a file in
the build tree, .kernelvariables.
We currently use this for ARCH, KERNELRELEASE, CC, and in some cases
also CROSS_COMPILE, CFLAGS_KERNEL and CFLAGS_MODULE.
This file can only be read after we establish the build tree, and all
use of $(ARCH) needs to be moved after this.
Gbp-Pq: Topic debian
Gbp-Pq: Name kernelvariables.patch
Ben Hutchings [Tue, 12 May 2015 18:29:22 +0000 (19:29 +0100)]
Make mkcompile_h accept an alternate timestamp string
We want to include the Debian version in the utsname::version string
instead of a full timestamp string. However, we still need to provide
a standard timestamp string for gen_initramfs_list.sh to make the
kernel image reproducible.
Make mkcompile_h use $KBUILD_BUILD_VERSION_TIMESTAMP in preference to
$KBUILD_BUILD_TIMESTAMP.
Gbp-Pq: Topic debian
Gbp-Pq: Name uname-version-timestamp.patch
Ben Hutchings [Tue, 24 Jul 2012 02:13:10 +0000 (03:13 +0100)]
Include package version along with kernel release in stack traces
For distribution binary packages we assume
$DISTRIBUTION_OFFICIAL_BUILD, $DISTRIBUTOR and $DISTRIBUTION_VERSION
are set.
Gbp-Pq: Topic debian
Gbp-Pq: Name version.patch
projects / linux.git / log